RECEIVED 

OCT 0 8 2004 

technology Center 2600 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re the Application of: 



Atty. Docket No.: 



004770.00026 



Toni Paila et al. 



Serial No.: 09/988,241 



Group Art Unit: 



2682 



Filed: 



November 19, 2001 



Examiner: 



West, Lewis G. 



For: 



MULTICAST SESSION HANDOVER 



Confirmation No.: 



8406 



SECOND DECLARATION UNDER 37 C.F.R, S 1.131 



The Honorable Assistant Commissioner for Patents 
Washington, D.C. 20231 



Sir: 



We, Toni Paila (Finnish), Jani Poikela (Finnish), Lin Xu (Chinese), Juha-Pekka Luoma 
(Finnish), and Rod Walsh (British), hereby declare that: 

1) We are the joint inventors of the above-captioned application, which is generally 
directed to Advanced Service Announcement for Broadcasting (ASAB); 

2) Prior to August 20, 2001, the filing date of U.S. Patent No. 6,731,936 B2 
(hereinafter "Chen"), we conceived of the invention recited in claims 1-47 of the 
above-captioned application, at least to the extent the claims are allegedly taught 
by Chen, and diligently pursued constructive reduction to practice in the form of a 
patent application filed with the United States Patent & Trademark Office. 

3) Prior to August 20, 2001, we developed a protocol specification for Advanced 
Service Announcement for Broadcasting (ASAB), a version of which is attached 
as Exhibit A. 

4) Correspondence at least as early as June 6, 2001 included a copy of the ASAB 
Protocol Specifications (see Exhibit B). 
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5) Concurrent to creating the ASAB Protocol Specifications, and also prior to 
August 20, 2001, we developed ASAB Server Side Specifications, a version of 
which is attached as Exhibit C. 

6) Correspondence at least as early as July 30, 2001 included a copy of the ASAB 
Server Side Specifications (see Exhibit D). 

7) Upon substantial completion of the specification documents attached as Exhibits 
A and C, we continued work on the development of ASAB, and prepared a 
disclosure document of an embodiment of the invention (Exhibit E). The 
disclosure document was submitted to the Nokia Internal Patent Committee at 
least as early as September 4, 2001, as evidenced in Exhibit E. 

8) The Internal Patent Committee evaluates and processes received invention reports 
on a first come-first serve basis After receiving an invention report, the Internal 
Patent Committee performs a patent search for relevant prior art in order to 
facilitate the patent filing decision. If a decision is made to proceed with the 
preparation of a patent application based on the invention report, the invention is 
assigned a rating from 0 to 5 based on the potential value of a resulting patent, 
and an instruction letter is sent to an outside counsel, with the invention report, 
requesting preparation of a patent application for the invention. 

9) After its in-turn review and analysis by the Internal Patents Committee, the 
disclosure document attached as Exhibit E was sent to our patent attorney, Mr. 
Bradley C. Wright of the law firm Banner & Witcoff, Ltd., on October 1, 2001, as 
evidenced by the email communication attached as Exhibit F. 
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10) On October 30, 2001, Ross Dannenberg (also an attorney with Banner & Witcoff, 
Ltd.) sent a draft of the above-captioned patent application to our employer for 
our review. A copy of the email communicating the draft is attached as Exhibit 
G. 

11) On November 13, 2001 Ross Dannenberg sent a revised draft of the above- 
captioned patent application. A copy of the email communicating the revised 
draft is attached as Exhibit H. 

12) On November 19, 2001, the above-captioned patent application was filed in the 
U.S. Patent and Trademark Office. 

13) The exchange of draft applications with our patent attorney demonstrates 
diligence from before August 20, 2001 until the filing of the above-captioned 
patent application and the constructive reduction to practice of our invention. 

14) All acts referred to in this Declaration were performed either in the United States, 
or in a WTO member country; 

15) The attached Exhibits have not been altered since they were originally submitted 
to the Patent Committee or otherwise prepared or communicated; and 

16) We declare under penalty of perjury under the law of the United States of 
America that statements made herein of our own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that 
these statements were made with the knowledge that willful false statements and 
the like so made are punishable by fine or imprisonment, or both, under Section 
1001 of Title 18 of the United States Code and that such willful false statements 
may jeopardize the validity of the application or any patent issuing thereon. 
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1. INTRODUCTION 



This is a protocol specification extending the basic SDP. This document is result of ASAB 
project and, thus the requirements for extensions come from the requirements of ASAB. 

The purpose of this document is to extend SDP beyond its current use in two ways. First, 
this means that use SDP to describe services instead of plain multicast sessions. A 
multicast sessions thus becomes a simple basic service. An example of another services 
that we want to describe is unicast connectivity. In addition, we consider several new 
parameters that are needed when services are announced in broadcast network. 

Second, we extend the SDP to be able to express cell-level mappings. This means, that 
there will be special annoucements that actually describe mappings between IP addresses 
and cell-paramenters. Thus, these announcements do not descrbe a specific "session". 

This document is structured as follows. 

• In chapter 3, we give two sets of requirements that are needed, but which the cunrent 
SDP does not fulfil. 

• In chapter 4, we describe the extensions to the basic SDP protocol to support new 
session-level attributes. The specification follows the principles of SDP specification. 
Thus we use ABNF together with a set of examples. 



In chapters, we extend the SDP father to cover the special mappings. The specification 
follows the principles of SDP specification. Thus we use ABNF together with a set of 
examples. 
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3. REQUIREMENTS FOR SERVICE DESCRIPTION PROTOCOL 

In this chapter we list and explain the requirements for the service description protocol. The 
base protocol for service descriptions was chosen to be SDP [1]. Thus this means, what 
kind of information we need to be able to express with SDP and how to extend it. The 
requirements listed in this chapter originate from ASAB requirement specification [2]. 

We have iterated, refined and categorised the requirements. There are two basic 
categories of requrements: session-level attributes and special mappings. The session- 
level attributes enhance the expression power of an single service announcement. The 
following is a set of requirements in that category 

1 . What is the cost of the service? Not all the services are freely accesible. Thus, it is 
necessary to be able to express the cost, cost mode and currency related to the service 

2. What is the availability and status of a service? The basic SDP expects that the 
session is directly available during the active time window (between start time and stop 
time). However, this is too restrictive. It is necessary to be able to express that the 
session is available dynamically, for example via voting. Moreover, the session can be 
off-air or on-air 

3. How to get the service and where to get it? It is necessary to be able to express the 
method of getting the service. For example, to receive an encrypted multicast service 
the user needs to send his authentication credentials to the network via a return 
channel. The user learns the IP-address of target host and the authentication 
mechanism through this extension 

Second category of extension contains the special mappings / services. There are four 
kinds of service descriptions that are needed: 

1 . Signaling the parameters of a DVB-T cell. We must be able to signal the detailed link 
level parameters of a DVB-T cell in an SDP announcement. This helps the client as the 
scanning time to find the link is greatly reduced. 

2. Mapping a set of IP multicast addresses to cell ids. Multicast sessions are carried 
on IP packets that have an multicast address. We must be able to define the mapping 
between a set of multicast addresses and the actual cell ids that contains the session. 
The receiver can then subsequently learn the cell-level parameters from the first type of 
an annoucement. 

3. What is the coverage of the service and how does it change? It is necessary to be 
able to express the coverage of the service in question in terms of logical, unique cell 
identifiers of an access system. In addtion, it is equally important to be able to signal 
the end users about future changes in the coverage. 

4. Describing logical service announcement channels. In some cases it is benificial to 
group the service announcements on a single logical channel. For example, in the case 
of DVB-T changing the reception frequency and re-tuning takes time. To help the 
receivers, there might be a cell that is used to annouce all the available sessions. One 
tuned to that cell, users receive fast all the annoucements and other mappings. 

5. Announcing unicast connectivity. This is to enable announcing of unicast 
connectivity (or to describe network access service, NAS). 
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4. PROTOCOL EXTENSION SPECIFICATION - SESSION LEVEL ATTRIBUTES 

There are two ways the following extensions in this chapter can appear. First, the new 
session level attributes can appear within a normal SDP description. In this case the 
extension attributes cannot be added, modified or removed by any third party (proxy) 
without breaking the SAP security checksum. 

Second, the new session level attributes can appear in a separate SDP description. In this 
case, there will be two (or more) announcements. The first one describes the basic 
session/service. Then, the latter one(s) just append (s) further information to the first 
description. The method to link additional annoucements to the original description is to use 
unique <sessionid> attribute. 

Using two separate annoucements is the recommended way to expand the SDP. 
4.1 Cost of service 

To be able to describe cost of a service, we introduce a new session-level attribute. 

a=cosL : <cosL> 

4.1.1 The ABNF for <cost> 

<cosL> = cosL-anounL space 

cosL-uniL space 
cosL-raLe space 
cog l-lype 

cosL-anounL = INTEGER 

cosL-uniL = "USD" / "EUR" 

cos I -rale = INTEGER 

; in case or Line based billinc 
; Lhis is Lhe interval in seconds 

cos L -type = "Line" / "size" / "one-oJJ" 

; deJTaulL "cne-o-TJ" 

4.1 .2 Example: Multicast session having time-based fee (using one annoucement) 

The following announcement describes a normal multicast session. In addition, cost- 
parameter tells that the cost of receiving the session is EUR 1 per hour. 

v=C 

o«nhandley 209C044 2090&420C7 IN IF4 126. 16 . 64 . 4 
s=£DF Seninar 

i=/\ Seninar on Lhe session descripLion proLocol 
u=hLLp: //www.cs.ucl.ac.uX/sLarr/M.Handley/sdp. C3. ps 
e=n~h@isi. edu (Mark HandleyJ 
c=IN IF'l 224.123.1.120/127 
L=2073397496 2073404696 
a=re evenly 

a=cost : 1 EUR 3600 time — 1 EUR/ hour 

n=audio 49170 RCF//\VF 0 
n=video SI 372 R1F//iVF 31 
n=applicaLion 32416 udp >4» 
a=orienL :por LraiL 
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4.1 .3 Example: Multicast session having time-based fee (using separate annoucements) 



This example describes exactly the same information as 4.1.2, but now using two separate 
announcements. This is recommended way. 

Announcement 1 - plain service description 

v-C 

o=nhandley 2&SC844;;26 2G9C0420C7 IN IF4 126 . 16 . 64 . '1 
c=SDF Seninar 

Seminar on Lhe oezoion description protocol 
u=hl Up: //www. . ucl . ac . uk/cla ~.T/M. Handley/sdp. C3 . pc 
e-*rr h@ ioi . edu (Mark Kandley) 
c-IK IF'l 224 .123.1.120/127 
1=2073397496 20734C4696 
o=re evenly 

n=audio 4 9 17 0 R7F/AVF C 
n-video 51372 R7F/AVF 31 
npapplicalion 32416 udp wb 
a=or ienl : por Lrai L 

Announcement 2 - additional cost information 

v=C 

o=operalor 123-156709 123-156709 IK IF4 111 . 122. 133 . 144 
c«*Cocl inJormaLion 
i-AddiLional cod in'omalion 
1=2073397/196 20734C4696 

a=ceccionid: nhandley 209C044526 IK IF4 126.16.64.4 
a=cost:l/EUR/3600/time — 1 EUR/hour 



Active time for a service is the time between start time and stop time as expressed by the t- 
field of an service description. Withing this active time, the service can be available in three 
ways. First, the session can be available statically. This is the default case in basic SDP. 
Second, the service can be available dynamically on-air or off-air. The service being on-air 
dynamically means that the service is currently available. However, the service may go off- 
air withing the active time. Last, the service can be available dynamically, off-air. This 
means that the service exists, but is not on-air currently. For example services that need to 
be voted or are based on popularity can first exist as dynamically off-air. When the service 
actually becomes available on-air, the service state changes to dymically available, on-air. 

To meet the requirements of expressing the service availablity, we introduce a new session 
level attribute 



When a service is announced as dynamically available, but currently off-air, we often need 
to specify how to get the service and where to contact. A new session-level attribute serves 
the purpose. 



4.2 Availability of service (dynamic/static) and contact information 



a=available: <available> 



a^conlacl :<ccnlacl> 
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4.2.1 The ABNFfor<available> 

<available> 



4.2.2 The ABNF for <contact> is: 

<ccnLacL> 
ccnLacL -address 



ccnlacl-lype 
proLocol 



"sLaLic" 

/ "dynanic/on-air n 

/ "dynamic/ o_"~-air" 

i J Lhis aLLribuLe is noL present , 

delaulL by RFC-2327 is "sLaLic" 

in case oJ dynamic /on-air or dynamic/o_\_'-air / 

consul L n a=conLacL" 



= conLacL-addr ess conlacl-Lype 
= I F4 -address 
"fthere Lo ceL" 

— Address cJ aLLendanL / server / ~ ci n listener 
where Lo send joins, eLc 

= proLocol 

; "How Lo eel" 

= "IGMF-JCIK" / "IGMF-VC7E" / "ICVvF" 



4.2.3 Example: Session available dynamically, currently off-air (using one annoucement) 

The following announcement describes a normal multicast session, which is offered to the 
end users. However, the session is not yet on-air (it's state is dynamic/off-air). Users can 
vote for the session to become on-air by sending a special IGMP-VOTE message to a host 
attendant.ucl.ac.uk. 

v=C 

o=nhandley 2090044^26 2090042007 IK IF'l 126.16.64.4 
s=SCF Seminar 

i=A Seminar on Lhe session descriplion proLocol 
u=hl Lp : //vrw. cs . ucl . ac . uK/ s laJJ/M. Handley/sdp. 0 3 . ps 
e=nr h@ i s i . edu (Mar K Hand le v ) 
c=IK IF4 224.123. 1. 120/127* 
L-20733S74S6 2073404696 
a= re evenly 

a=available: dynamic/off-air 

— see the <contact> parameter to see more 
a=contact : attendant . ucl . ac . uk/ IGMP-VOTE 

m=audio 45170 R7F/AVF 0 
m=video 51375 R7F/AVF 31 
n=applicaLion 32416 udp wb 
a-orienL : por LraiL 

4.2.4 Example: Session available dynamically, currently off-air (using separate announcements) 

This example describes exactly the same information as 4.2.3, but now using two separate 
announcements. This is recommended way. 

Announcement 1 - plain service description 



o=mhandley 2090044526 2090042007 IK IF4 126.16.64.4 
s-SCF Seminar 

i=/\ Seminar on Lhe session descripLion proLocol 
u^hL Lp : //-www. cs . ucl . ac . uk/s La__7/M. Handley/sdp. 0 3 . ps 
e=rr h@ isi . edu (Mark Handle*/ J 
c~IK IF4 224.123.1.1207127 
L=2073397496 2073404696 
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a= re evenly 

o-QudLLe 4911 C R7F/AVF C 
n=videe 51372 R7F/AVF 31 
reapplied I ion 32416 udp T^b 
a~orienl ; per Irai L 

Announcement 2 - additional availability information 

v=C 

o=cperalcr 12345670$ 12345670$ IN IF4 111.122.133.144 

c=Ccsl inJcr nation 

i=/*»ddi lional cocL inJomalion 

L-20733S74S6 20734C4696 

a=ceccionid: nhandley 20SC044526 IK IF4 126.16.64.4 
a=available: dynamic/of f- air 

— see the <contact> parameter to see more 
a=contact : attendant . ucl . ac . uk/ IGMP-VOTE 
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5. PROTOCOL EXTENSION SPECIFICATION - SPECIAL MAPPINGS 

5.1 DVB-T cell parameter announcement 

This announcement describes the physical transport parameters of a single DVB-T 
broadcast cell. The following ABNF extends the SDP syntax defined in RFC 2327. In 
addition, new session- and media-level attributes described below are defined for the 
announcement. 

The complete DVB-T cell parameter announcement thus consists of two parts: connection 
parameter and cell-describing attributes as session-level or media-level parameters. 

c=<nel Lype> <addrtype> <ccnnec t ion- addr ess> 

<cell-attribute-Jields> 

<cell-nedi a-Tieldc> 



5.1 .1 The ABNF for <nettype> ( <addrtype> and <connection address> 



<ne I lype> 
<addrtype> 



"CVE/CEll" 

m "IFd" / "SI" 

IF'l : IFvl address identifies Lhe cell 
SI: cell_id in DVB Service Information 
identifies Lhe cell 

noLe - should be exL ended later Lo cupper L IPv6 as -well 



<connection-address> 



«■ dvb-cell-addr 



dvb-cell-addr 
dvb- ce 1 1 -i -addr 

dvb- ce 1 1 -s i- addr 
original-network-id 

dvb- cell-id 

decinal-ushort 



= dvb-cell-ip4-addr / dvb-cell-si-addr 
= uni cast -addr 

; uni cast -addr defined in RFC 2327 

; ncLe - privaLe IF address es should NCI be used 

; as cell IDs 

= original-network-id "/" dvb-cell-id 
= decimal -ushorL 

; original_netwcrk_id defined in DVB SI 

= decinal-ushort 

; cell_id defined in DVE SI 

= 1* (DIGIT} 

; unsigned 16-biL inLeger 



5.1 .2 The ABNF for <cell-attribute-fields> 

<cell-at tribute-f ields> = noma 1 -cell -a I tribut e-Tields 

/ abbrevi a L ed-cel 1 -a L L r ibu L e-f i e Ids 
; based on <al tribute-f ields> defined in RFC 2327 
; nandaLory sub- fi elds indicated in cements below 

nornal -cell-attribute-fields = *<"a=" nomal-cell -at tribute CR1F) 

abbreviated-cell-attribute-fields = *("a=" abbreviated-cell-attribute CR1FJ 



nomal -cell- at tribute 



= bandwidth 
/ ~ft-node 
/ constellation 
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/ coder ale 

/ cuard-inLerval 

/ hierarchy 

/ hierarcliical -priority 

/ dvb-Jraninc 

/ noma 1 -bearer 
; Lhece DVE-T parameters defined in Lhe 
; CVB SI specification 



abbreviated-cell -a I tribute = dvb-rraninc 

/ abbreviaLed-bearer 



bandwidth 

"I -node 

cone Lellalion 

coderaLe 

cuar d- interval 

hierarchy 

hierarchical -priori Ly 

dvb-_Traninc 
dvb- ~r aninc-node 

normal -bea re r 

a bb r e v i a L e d- be a r e r 

nomal -dvb -bearer 
abbr ev i a L ed-dvb- be a r e r 



bandwidth- at LribuLe 



= "dvb-l-bandwidlh: n bandwidlh-allribule 
; nandalory 

= "dvb-L-r_X: " Jri-node-al tribute 
; mandatory 

= "dvb-l-ccnslellation: " cone Leila lion-allribule 
; nandalory 

= "dvb-l-coderale: " coderale-allribule 
; nandalory 

= " dvb- L -cua r d -i n I e r va 1 : " cuard-inlerval-a I tribute 
; nandalory 

= "dvb- I -hierarchy: " hierarchy-aLtribule 
; nandalory 

= "dvb-l-hierarchical-priorily: " 
1 li er a r chi ca 1 -pr i or i I y- a 1 1 r i bu I e 
; iencred i_T hierarchy == "none" 
; nandalory i~ hierarchy != "none" 

- " Irani nc : " dvb-_"raninc-node 
; nandalory 

= "dvb/npe" 

; DVE nul I i protocol encapsulation, 

; other alternatives could be added here 

= "bearer:" nomal-dvb-bearer 
; nandalory 

= "bearer:" abbr evi a led-dvb- bearer 
; mandatory 

= "dvb-t" 

= "dvb- I" 

space bandwidlh-allribule 

space *_"l-node-a t tribute 

space cone I ell a lion- at tribute 

space coderale-allribule 

space cuard- interval -at tribute 

space hierarchy-attribute 

[ space hierarchical -priority-attribute [ 

; bandwidth in MKz 



rt-node-alt ribuLe 



= "2" / "0" 

; FFT node used/ 2 k or Ok 
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constellation-attribute = "QF£K n / "16G r '*M n / n 6<*G/*f n 

codezate-attribute = "l/2 n / "2/3" / "3/4" / "i/6" / "7/0" 

•ruard-interval-attribute- n l/32 n / "1/16" / "1/0" / "1/4" 

hierarchy-attribute - "none" / "1" / "2" / "'1" 

; alpha value Tor 

; hierarcliical codinc, or "none" ±1 

; hierarcliical coding is no I used 

hierarchical -priority-attribute = "low" / "hich" 

5.1 .3 ABNF for <cell-media-fielcls> 

<cell-nedia-rields> = 1* (cell-nedia-Tield; 

cell -nedia-~i eld - n nF=nas/none" CR1F cell-nedia-at tributes 

cell-nedia-attributes = l*( n a= n cell-subcell-attribute CFCF} 

cell— subcell -attribute = "subcell:" [ dvb-subcell-id space " 

eel l-central-~requency-at tribute 
[ "/" cell -coverage-attribute ] 

dvb-subcell-id = decinal-uchar 

; decinal-uchar defined in RFC 2327 
; subcell_id defined in CVE £1 

cell -central -frequency-attribute = -1 cq L 

; central frequency in MHz 

cell -c over oce-at tribute = "coverage:" center-coord "/" radius 

Jioat = * (digit; "." i* (digit; 

center -coord = 11 oat ("K" / "S") "/" float ("E" / "W" ) 

; in decrees, latitude and longitude 

radius = Ileal "/" float 

; in kilometres, north -couth and east -west 

5.1.4 Example: Mapping of (sub)cell ids - normal notation 

The following announcement introduces a DVB cell, identified by the IP address 
15.21 .12.34. The session-level attribute fields with the prefix "dvb-t-" descibe DVB-T link 
level parameters, common to all subcells of a DVB-T cell. Last, two media sections in the 
end identify two subcell s with subcell IDs 1 and 2, each with different geographical 
coverage. 

v-C 

o=- '13C593C02 232365346 DC IF A 131.228. 32.59 
c=KetworK /vecese Service ( NAS ) announcement 
i=Faraneters Q- a DVB-T cell and subcells 
crDVB/CELL IP4 15.21.12.34 
a=dvb- t-bandwi dth : 8 
a=dvb-t-fft: 8 

a=dvb-t-constellation: 16QAM 
a=dvb- t-co derate ; 2/3 
a=cVb-t-guard- interval : 1/8 
a=dvb- t-hi er archy : none 
a=dvb-t-hierarchical -priority: high 
a=framing: dvb/njpe 
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a=bearer : dvb -t 

l=H9032CC 1274217 
in=nas/none 

a=subcell : 1 450 . 2/60 . 31N/12 . 44E/3 .1/2.5 
m=nas/none 

a=subcell : 2 516 . 3/60 . 28N/12 . 45E/2 .9/2.8 

5.1 .5 Example: Mapping of (sub)cell ids - abbreviated notation 

The following announcement descibes the DVB-cell in a shorter, abbreviated notation. This 
notation bundles all the link-level parameters of a DVB-T cell into one bearer attribute field. 

In this case, the cell is identified by the IP address 15.21.12.35 and contains just one 
subcell (a DVB-T cell always consists of at least one subcell in the ASAB announcement 
syntax). The optional subcell ID parameter has been omitted from the cubceii field, as 
there is no need to differentiate between the subcells of this cell. 

v=C 

o=- 430593002 232365346 IK IF'l 131.220.32.59 
o=Kelvrork success Service (KfvSJ anncuncenenL 
i=Faranelerc or a CVE-7 cell and cubcellc 
a=DVB/CELL IP4 15.21.12.35 
a=framing: cVb/n^e 

a=bearer : dvb-t 8 8 16QAM 2/3 1/8 none 

L-49032CC 127^217 
n=nac/none 

a=subcel l:491.23/23.59S/90 . 63W/4 0.9/38.5 

5.1.6 Example: Mapping of (sub)cell Ids -abbreviated notation 

This announcement describes the paramters of a DVB-T cell consisting of three subcells. 
Because the hierarchy-attribute subfield contains a value other than "none", the 
hierarchical-priority-attribute subfield must be included, and has a value of "high" in this 
case. The inclusion of subcell coverage parameters is recommended, although not 
mandatory - in this example the coverage parameters have been omitted. 

v=C 

c— 430593002 232365346 IK IF'l 131.228.32.59 
c=Kelwork Accede Service (NTvS; announcement 
i= Parameters o_" a CVE-7 cell and Gubcells 
c=DVB/CELL IP4 15.21.12.36 
a=framing: dvb/inpe 

a=bearer:dvb-t 8 8 64 QAM 1/2 1/16 2 high 

1=4903200 1274217 
n=nac/none 
a=subcoll;l 460.1 
n^nac/none 
a=subcell:2 510.5 
nr=nac/none 
a=subcell:3 570.9 



5.2 Mapping from DVB-T cells to sessions 

This announcement identifies one or more DVB broadcast cells, and for each cell describes 
the group of sessions being transmitted in that cell. New media-level attributes described 
below are defined for the DVB-T cell to session mapping announcements. In addition to the 
mapping announcements defined here, clients also need to receive normal SAP 
announcements describing the sessions. 
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Similarly to DVB-T cell parameter announcements described earlier, cell-to-session 
announcements consist of two parts: a <dvb-neL>jork-ccnnecLion-::ieid> identifying the 
DVB network, and media-level attributes defined as <ceii-oap P inc-nedia-jieidc>. 

The following subsections extend the SDP syntax defined in RFC 2327. The ABNF entries 
ccnnecuon-jieid and nedia-deocripUono defined in RFC 2327 are replaced by <dvb- 

neL>rork-connecLion-~ield> and <cell-nappinc-nedia- Jields>, respectively. 

5.2.1 The ABNF fbr<network-connection-field> 

<dvb-neLwork-connec Lion- Zie ld> ~ "c=" neLwork-neLLype 

cpace neLvork-addrLype 
space network -c cnne c t i on - addr es s CRIF 

neLwork-neLLype = "EVPATIftCRK" 

neLwrk-addrLype = "SI" 

neLwork-connecLion-addr ess = dvb-neLwork-addr 



dvb-neLwork-addr « original -neLvrork-id 

original -network -id = decimal -ushorL 

; original_neLwork_id defined in DVB SI 

decinal-ushorL - 1* (DIGIT) 

; unsigned 16-biL inLeger 

5.2.2 The ABNF for media-level attributes 

<cell-napping-nedia-rields> = 1* ("n=nas/none" CR1F 

cell-connecLion-Jield CR1F 
cell -nappi ng-aLL ri buLe-Tields ; 

cell-ccnnecLion-Jield = "c=" neLLype space eel 1-c-addr type -addr 

cell-napping-aLLribuLe-Jields = l*("a=" unique-session-id-aLLribuLe CFZ.F) 

cell -neLLype = "CVE" 

cell -c -addr Lype-addr - "CEIL" dvb-cell-addr Lype dvb-cell-addr 

unique-session-id-aLLribuLe - "sessionid:" usernane space sess-id space 

neLLype space addr Lype space addr [":" Lining* 
; globally unique session idenLi-Tier LhaL naps Lo 
; Lhe "o=" lie Id el an RFC 2327 session announcenen L 

dvb-cell-addr Lype * "IF'l" / "SI" 

dvb-cell-addr = dvb-cell-ip'l -addr / dvb-cell-si-addr 

usernane = saJe 

; usernane and sale defined in RFC 2327 

sess-id = 1* (DIGIT) 

; sess-id defined in RFC 2327 

; should be unique Tor Lhis criginaLing usemane/hosL 

addrLype - "IF^" / "IF6" 

; addrLype defined in RFC 2327 
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addr = FQDK / unicasL -address 

; addr, FQCK and uni ca s L- addr ess defined in RFC 232" 

dvb- ce 1 1 -i -addr ™ uni casL -addr 

; unicasL-addr defined in RFC 2327 

dvb- cell -si -addr = oricinal-neLwcrk-id dvb-cell-id 

or icinal-neL work-id - decimal -us horL 

; oricinal_neLvcrk_id defined in DVB SI 

dvb-cell-id - decimal -ushorL 

; cell_id defined in DVB SI 

decinal-ushorL = 1* (DIGIT) 

; unsigned 16-biL inLecer 



5.2.3 ABNF for <timing> 

<Lininc> = sLarL-Line s Lop- Lime 

; Lhe Line Lhis aLLribuLe becomes acLive 

; - 11 Limine does noL exisL, assume session 

; level L -aLLribuLe 

; -11 sLarL-Lime == C, assume session level sLarL-Lime 

; - 11 s Lop-Line -= C, assune session level s Lop- Line 



5.2.4 Example: DVB-T cell to session mappings 

The following announcement declares that the DVB cell identified by IP address 

15.21 .12.34 contains three multicast sessions and the cell identified by IP addrss 

15.21 .12.35 contains four multicast sessions. The contained sessions are refereed with 
session id-attribute. Note that both cells contain the session (a=sessionid> 3398739487 IN 
IP4 136.34.12.2). Note also that the session (a=sessionid> 3398739487 IN IP4 
136.34.123.26) Migrates from cell 15.21.12.34 to 15.21.12.35. The transition takes palce 
during time interval 344430000.. .344450000. 

v=C 

o=- 337457329'! 339S107242 IK IF'l daLacasL.dici La. 11 
s^NeLwork Access Service (K/\S) announcemenL 
i=Mappinc Iron CVE-r cell ( c- ) Lo sessions 
c=DVB/NETWCRK SI 32765 
L=33S071507'1 0 
m=nas/none 

c=DVB/CELL IP4 15.21.12.34 

a=sessionid: - 3398737481 IN IP4 136.34.12.2 
a=sessionid: - 3398739487 IN IP4 136.34.123.26 0 344450000 
a-sessionid: - 3398983458 IN IP4 mediacast.sonera.fi 
a=sessionid: admin 3398778932 IN IP4 138.34.253.9 
HF=nas/none 

c=DVB/CELL IP4 15.21.12.35 

a=sessionid: - 3398737481 IN IP4 136.34.12.2 
a=sessionid: - 3398739487 IN IP4 136.34.123.26 344430000 0 
a=sessionid: - 33989834 53 IN IP4 mediacast.sonera.fi 
a=sessionid: root 3398798446 IN IP4 139.43.56.76 
a=sessionid: demo 339877334 8 IN IP4 roediacast.sonera.fi 



NOKIA 



ASAB PROTOCOLS 



17(25+) 



Nokia Research Center 
Toni Paila 



v0.055,| 



5.3 Mapping from sessions to DVB-T cells 

It is necessary to be able to define the coverage of a service in terms of logical scope. We 
define the scope in terms of a list of cells. In addition, it is necessary to describe such 
actions as coverage expansion, coverage contraction and migration of service from a cell to 
another. This section explains how to achieve all this. 

We intruduce a new announcement that identifies one or more sessions, and for each 
session describes the group of DVB-T cells where the session is being transmitted. New 
media-level attributes described below are defined for session to DVB-T ceil mapping 
announcements. In addition to the mapping announcements defined here, clients also need 
to receive normal SAP announcements describing the sessions. 

Similarly to DVB-T cell parameter announcements described earlier, cell-to-session 
announcements consist of two parts: an optional <dvb-neLwork-connecLion-rieid> (defined 
in 5.2.1) identifying the DVB network, and media-level attributes defined here as <zeos- 

nappinc-nedia-TieldG>. 

The following ABNF extends the SDP syntax defined in RFC 2327. The ABNF entries 

connecLion-jieia and media-decor ip i ions defined in RFC 2327 are extended by <dvb- 

neLivor K-connecLion- Jield> and <cecc-nappinc-nedia-Tields>, respectively. 



5.3.1 The ABNF for media-level attributes 

<£ecc-nappinc-nedia-_"ieldc> = 1* ("nRnas/ncne" CRLF 

n a=" unique-seccion-id-allribule CR1F 

zezo -nappi rag - a L L ri bu I e -Ti eldc J 

; unique-ceccion-id-allribule defined earlier 

oeoo -nappi nc-allribule-Tield:- - l*("a=" cell-id-aLLribuLe CR1FJ 

cell-id-al LribuLe = "cellid:" dvb-cell-addr lype space dvb-cell-addr 

["/" cell-id-rancel [ n : lining; 
; dvb-cell-addrLype and dvb-cell-addr defined earlier 

cell-id-rance = PCS -DIGIT * (DIGIT) 

; number oT ccnceculive cell ids - IT no 
; cell-id-rance ic- (riven, ±o accuned 



5.3.2 Example: session to DVB-T cell mappings 

The following announcement is an example of DVB-T cell mappings. All media descriptions 
in cell mappings start with the "m=nas/none" m-field 2 . In each media description, a session 
identided by the ceccionid field is mapped to one or more DVB-T cells identified by ceiiid 
fields. Because multiple media descriptions can be included in an announcement (as with 
standard SDP [1]), this announcement format allows any number of sessions to be mapped 
to the cells delivering those sessions. 

TTie inclusion of a c-field with the networkjdenSfter [8], [9] of a DVB network is 
recommended but not mandatory. 



2 The syntax of this form of the m-field originatesfrom the Media Gateway Control Protocol specification [6] 
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o=- 337d5732S5 339Sl072d3 IK IFd dalacasl . dici la. Ji 
o=KeLwrk Accecz- Service (K/\SJ announcenenL 
i^Iappinc JTron ce^cion (o ) Lo CVE-T cells 
o=CWB/NETWCRK SI 32765 
1=3390715074 C 
ro=nas/none 

a=sossionid: - 3398739487 IN IP4 136.34.123.26 
a=cellid:IP4 15.21.12.34 
a=cellid:IP4 15.21.12.35 
nF=nas/nonQ 

a=sessionld: - 3398983458 IN IP4 mediacast.sonera.fi 
a=collid:IP4 15.21.12.34 
a=c©llid:IP4 15.21.12.35 
m=nas/none 

a=sessionid: admin 3398778932 IN IP4 138.34.253.9 

a=c©llid:IP4 15.21.12.34 

m=nas/nona 

a=sossionid:root 3398798446 IN IP4 139.43.56.76 

a=cellid:IF4 15.21.12.35 

nF=nas/none 

a=sossionid: demo 3398773348 IN IP4 inediacast.sonera.fi 
a=cellid:IP4 15.21.12.35 

5.4 Describing logical service announcement channels 

In this case we want to announce the presence of a logical channel (for example a cell) that 
further contains service announcements. We achieve this with a new individual SDP 
description. The method is modified from a proposed way of describing session de re dories 
with SDP [3]. 

The session-level connection parameter (c-field) specifies the actual multicast address of 
the announcement channel. Then, session-level attribute a=cellid uniquely defines the cell, 
in which the above mentioned multicast address is available. Media parameters are set os 
descrbed in [3]. Last, media-level attribute a=cellid can be used to specify to which cells the 
announcements belong. 

5.4.1 ABNF for a logical service announcement channel description 

<locical service announcenenL channel deccriplion> 

= v- "ield 
c-Jield 
o-lield 
c-JTield 

* (cell -reference ) 

* (c-dr -nedi a - bundl e J 

cell -reference = cell-id-allribule 

cdr-nedi a -bundle = cdr-nedia-Jomal 

* (cell -re-Terence J 



5.4.2 Example: announcing neighbour control channel of neigbouring cells 

The following description presents an example how a cell can announce the control 
channels of it neigbour cells. These channels then in turn contain majority of 
announcements related to the espective cell. 
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o~nhandley 20$CDdd526 20SC0d20C7 IK IF4 126 . 16 . 64 . 4 
s=Locical control channel announcement 

c=IK IFd 224 .2. 127.2^2/2^ — UBA specific eel 1-1 oca 1- arm. nullicaol croup 
a==cellid: IP4 15.21.12.22 — Where is the racast address of c-field available 

L-C C 

m=appl icat ion 9875 SAP SDP 

a=cellid:IP4 15.21.12.22 — Target cell #1 to be described 
a=cellid;IP4 15.21.12.23 — Target cell #2 to be described 
a=cellid:IP4 15.21.12.24 — Target cell #3 to be described 



The following presents an example of how to announce logical announcement channels 
with SDP. The service description below expresses that the IP address 224.2.127.252 
carries a control channel for cells 15.21.12.34, 15.21.12.31 and 15.21.12.32. For the first of 
these the description protocol is SDP and for the two last ones the description protocol is 
SDL-XML. The identical service announcement channel carrying 224.2.127.252 is available 
in cells 15.21.12.22 and 15.21.1226. 



o=nhandley 20900^26 20$C0'120C7 IK IF'l 126. 16 . 6'] . '1 
c=locical conLrol channel announcenenl 

c=IN IF'l 224 .2. 127. 252/2 35 — UEA cpeciTic eel 1-local-ann. nullicasl croup 
a=cellid:IP4 15.21.12.22 — Where is the mcast address of c-field available 
a=cellid:IP4 15.21.12.26 — Additional cell, where the mc addr is available 

L=C C 

m=appl icat ion 9875 SAP SDP 

a=cellid:IP4 15.21.12.34 — Target cell #1 to be described 
m=appl icat ion 9876 SAP SDP-XML 

a=cellid:IP4 15.21.12.31 — Target cell #2 to be described 
a=cellid:IP4 15.21.12.32 — Target cell #3 to be described 



This announcement defines the mapping of DVB service components to IP addresses 
within a single DVB-T broadcast cell. These announcements only need to be transmitted in 
cells carrying IP data on more than one PID. 

The DVB service component to IP address mapping consists of two parts: a <dvb-ceii- 
connecLion-rieid> identifying a DVB cell, and media-level attributes defined as <ccnp- 

nappinc-nedi a -Zi eldc> . 

The following subsections extend the SDP syntax defined in RFC 2327. The ABNF entries 

connecLion-rieid and nedia-deccripLicn^ defined in RFC 2327 are replaced by <dvb- 

cell -conned ion-rield> and <conp-nappi nc -nedi a-_Ti el dz> , respectively. 

Notice the slightly non-standard use of the subnet mask length in the subnei-aiiribuie 
field defined below. In ASAB announcement protocol, the subnet mask length is used to 
indicate individual IP addresses or address ranges, for both unicast and multicast IP 
addresses. If the subnet mask length is smaller than the length (in bits) of its associated IP 
address, a range of IP addresses is described. However, if the subnet mask has the same 
length as the IP address, an individual IP address is indicated. 



5.4.3 Example: describing control channel 



5.5 Mapping DVB service components to IP addresses 
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For example: 

subnet \224 . C . C. C/16 — A cub:; eel ion oZ the multicast IF address 

— ranee (22d .0 . C. 0 - 224 . C. 255 . 255) 

subnet : 236. 25. 243. ISC/32 — An individual multicast IF address (236.25.2-13.190) 

5.5.1 The ABNF for <cell-connection-field> 

<dvb-cell-connecticn-rield> = "c 3 " cell-neLLype 

space cell -addr type 

space cell-connection-address CR1F 

cell-neLLype = "CVE" 

cell-addrtype = "CEll" 

cell -conned ion-address «■ dvb-cell-addrLype space dvb-cell-addr 

; dvb-cell-addrLype and dvb-cell-addr defined earlier 

5.5.2 The ABNF for <comp-mapping-media-fields> 

<conp-nappinc-nedia- ~ields> «» 1* ("m=nas/none" CR1F 

conp-connection- "ield CR1F 
conp-nappi ng - a L L r i bu L e - Zi elds J 

conp-connection-Jield = n c=" conp-c-neLLype-addrLype space 

s e r vi ce-compon en L 

comp-c-nellype-addrlype = n CVE/'SERVICE n 

comp-mapping-at tribule-Jields = l*("a=" subneL-aL LribuLe CR1F : 

subnel-allribule = "subnet:" sufcnet-net type space subnel-addrl ype space 

subnel-addr "/" subnet -mask-length 
; describes an address ranee 
; extends Lhe definition Jron RFC 27 05 
; nole - subnets being transmitted within the sane 
; EVE-T cell nust net overlap 

subnet -net type = "IK" 

subnet -addr type = "IFd" / "IF6" 

subnet -add r = unicast -address / rtulli cast -addr ess 

; unicast -addr ess and multicast -addr ess defined 
; in RFC 2327 

subnet -nock- length « decinal-uchar 

; length (in bits J o_T Lhe subnet mask 
; decinal-uchar defined in RFC 2327 

service-component = service-locator ["/" component-lag] 

; component-lag can be leJt out ±Z the service 

; contains only one data broadcasL component carryi ng 

; IF over MFE 

subneL - "IK" space 

subneL -addr L ype space 

subnet -addr V" subnel-nask-lenglh 

service-locator = service-path / textual-service-identiJier 
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ccnpcnenL-Lac = decimal -uchar 

service-paLh = cricinal-neLwork-id 

service-id 
; cricinal-neLwrk-id defined earlier 

Lex Lual-cervice-idenLi Tier = FQCK 

; FQCK ( Jul ly-'^uali Tied dona in none' defined in RFC 2327 

serv ice-id = decinal -usher L 

; decinal -usher L defined earlier 
; service id defined in DVE SI 



5.5.3 Example: Mapping IP addresses to DVB service components 

The example below shows the mapping of the entire multicast IPv4 address range 
(224.0.0.0 - 239.255.255.255) to four components of a DVB service being broadcast in a 
DVB-T cell. The cell is identified by a c-field in the session-level part of the announcement. 
The mapping from IP address ranges to DVB service components is defined in the media- 
level part of the announcement, consisting of one or more media descriptions. Each media 
description includes a c-field identifying a DVB service and a component within that service. 
The media description further contains one or more subnet fields that describe the address 
ranges being transmitted on the given service component. 

In this example, the selection between the four components takes place according to the 
two most significant bits of a multicast IPv4 address, following the four-bit address prefix 
that is constant for all multicast IPv4 addresses. Thus, a subnet mask length of 6 bits is 
used in the subnet fields below. 

v=C 

o=- '15022072 '1 502732034 IK IF'l daLacasL . sonera . -i 
c=KeLvrork Access Service (KfiSJ announcenenL 
i=IF address Lo CVE service ccnponenL nappincs 
C=DVB/CELL IP4 131.228.7.11 
m=nas/none 

c=DVB/ SERVICE multicast . medianet . sonera . f i / l 

a=subnet:IN IP4 224.0.0.0/6 

m=nas/none 

c=DVB/ SERVICE multicast . medianet . sonera . f i /2 

a=subnet:IN IP4 228.0.0.0/6 

in=nas/none 

c=DVB/ SERVICE multicast . medianet . sonera . f i/3 

a=subnet:IN IP4 232.0.0.0/6 

m=nas/none 

c=DVB/ SERVICE multicast . medianet . sonera . f i /4 
a=subnet:IN IP4 236.0.0.0/6 



5.6 Access mappings 

Access mappings enable clients to obtain a return data path to a media operator that offers 
a datacasting service via DVB-T. Clients can then be provided with a "hybrid network" 
connection to the Internet, where the forward data path is provided via DVB-T and the 
return data path via some other network. The availability of a return data path enables 
clients to use unicasl protocols and/or participate in 'Voting 1 ' for the selection of dynamic 
multicast content on the DVB-T network. 
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By sending access mappings, datacast operators can provide clients the IP address of a 
login server or the phone number of a modem pool. Providing an IP address is preferable, 
as clients are then free to use any Internet Service Provider (ISP) for connecting to the 
media operator. General-purpose ISP phone numbers may also be advertised using 
access mappings, without requiring the client to use a particular ISP. 

Access mappings consist of standard SDP session and time attributes, followed by the 
media-level attributes defined in the following as <access-media-fields>. 



5 .6.1 The ABNF for access mappings 

<access-nedia-Tields> 
accecc -media -Ti eld 

access -nas -Tield 
access -conneclion-Tield 



1* (access-nedia-Tield) 

"hp" access-nas-Tield CRZF acces s- conn eclion-Ti eld CR1F 
access-allribule-Jields CR1F 

"nao/" nas-aulhenlicalion 

"c=" c-access-nellype space c-a c ce -add r type space 
c-access-connec Lion- address CR1F 



access -all ribuLe-Ti elds = 1* ( n a=" access-allribule-Tield CR1F) 

; mandalory access allribules indicaled below 



nas - au Lhen li ca I ion 



c-access-nel lype 



c-a c ce s s -add r I ype 



- "none" / "locin" / "chap" / "pap" / "ipsec" / "12lp" 
; Ihese aulhenlicalion nelhods deJined in RFC 27C5 

= "IK" / "IK" 

; TK Tor Telephone Kelwork, as in RFC 28 '10 
= in-addrlype / In-addrlype 



c-ac cess -conned ion- address = in-connec I ion- address / In-connec lion-address 



access-allribule-rield 



in-addrlype 
In-addrlype 

in-connecl ion-address 

In-connecl ion-address 
Traninc-al Iribule 

bear er -a 1 1 ri bu I e 
inp-addr 



= Traninc-allribule 

/ bearer-allribule 

/ eel 1-id-a I Iribule 

/ subnel-allribule 
; nandalory cell -id-al Iribule defined earlier 
; subnel-allrilxile defined earlier 

= "IF>i n / "IF6" 

= "RFC2o'13" 

; I his address Lype deJined in RFC 204 0 
= FQCK / unicasl-addr 

; FQCK and unicasl-addr defined in RFC 2327 

= inp-addr / ldp-addr 

= "Traninc : " Traminc-node 

; indicales Lhe layer 2 Traminc used 

; exlends lhe deTinilion Trom RFC 27 05 

= "bearer:" bearer -Lype 

; ex Lends Lhe deTinilion Trom RFC 27 CO 

= " " PCS -DIGIT C*<{ n - n CIGIi; / DIGIT) 

; clobal phone number, 

; deTined as IKF/*,ddr in RFC 20 40 
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ldp-addr 



Traninc-node 



bearer-Lype 

ncden- bearer 
icdn -bearer 

ncden- o L anda rd 

noden-nanuTac Lurer 
icdn-o Landard 



cigi:: o*<r- n digit; / digit; 

local phone number, 

defined ac IDF/vddr in RFC 2£M0 

dvb- Traninc-node / 
"ppp-sync" / 
" PPP~ a e yn ch n / 
"ppp-hdlc" / 
"clip" / 
"acynch" 

dvb-Traninc-ncde defined earlier 

nomal-dvb-bearer / noden-bearer / icdn- bearer 
nomal-dvb-bearer deTined earlier 

noden-s Landard ["/" noden-nanuTacLurer 

"ic-dn" * (DIGIT; ["/" icdn-c Landard; 
example valuer*: "icdnSfc", n icdn6'l n , 
n icdn6d/v.llC n , n icdn64/v. 12C" 

("v." l*(alpha-nuneric; J / 

n x2 n / 

n k56riex n 

example values: "v,32", "v. 34", "v. 90", "x2", "k56Tlex" 
l*(sarej 

exanple values: "3con n , "rockvell" 



exanple values 



.110", "v. 120" 



5.6.2 Example: Announcing a return data path to a media network operator via a modem pool 

The following example announces two dial-in modem numbers that clients can use to 
obtain a return data path to a media operator. The cell id(s) associated with each phone 
number indicate the recommended dial-in number for clients, based on the location of each 
client. 

Each phone number is announced within a media description that starts with an m-field. 
The m-field is of the format n m=nas/xxx" identifying an authentication method for a Network 
Access Service, as defined in [6]. In this example, the authentication method "login" 
indicates that end-users will be prompted for a username and password for authentication. 

Each media description contains a c-field describing a connection address for the return 
data path, given in this example as the phone number of a modem pool. Additional 
parameters describing the modem type (bearer attribute [6]) and link-layer framing (Traninc 
attribute [6]). Finally, one or more cells are identified (using the ceiiid attribute) as a target 
area where each return data path connection address should be used - for example to 
provide a local PSTN number to end-users where possible. Note that the same cell id can 
be listed in more than one media description within an access mapping. 

v=0 

0— 3-16232972 920CC2i3'13 IK IF'J 131.220.32.^9 
£«*KeL>fcrk /'iccecc Service ( KA£ ) a nnouncenen L 

1- £ubneL Tor DVB MFE encapculaLed IF da La 
m=nas/ login 

o=TO RFC2543 +358-2-2340982 
a=framing: ppp-asynch 
a=bearer : v . 90 
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a=cellid:IF4 160.237.53.1/8 
m=nas/ login 

c=TN RFC2543 +358-3-5837272 
a=framing: ppp-asynch 
a=bearer : v . 90 

a=cellid:IF4 160.238.45.1/4 
a=cellid;IF4 160.238.4 6.1/4 



5.6.3 Example: Announcing a return data path to a media network operator via Internet 



Similar to the the previous example, the following announcement describes the connection 
addresses for obtaining a return data path to a media operator. As in the above example, a 
number of cells is mapped to each connection address. The difference to the proceeding 
example is that each connection address here is given as an IP address. This allows clients 
to use their most preferred Internet Service Provider to connect to the indicated IP address. 

v=C 

c=- 34 6232572 920CC25'13 IK IF A 131.220.32.59 
c«Kelwork Access Service ( KAS ) announcenenl 
i=Subnel Jor CVB MFE encapsulated IF da La 
m=nas/ login 

o=IN IP4 portall.inediacast.sonekra.fi 
a=cellid;IF4 160.237.53.1/8 
m=nas/ login 

c=IN IP4 portal2.iRediacast.sonera.fi 
a=cellid:IP4 160.238.45.1/4 
a=cellid:IP4 160.238.4 6.1/4 



5.6.4 Example: Announcing connectivity to an Internet service provider via a modem pool 



While the earlier announcement leaves clients with the freedom of choosing an ISP, a client 
may not always be configured with the cunrent ISP connectivity details. This announcement 
informs clients about available ISP dial-in numbers. One or more Cell ids are optionally 
associated with each phone number, to indicate the recommended ISPs for clients 
depending on their location. 

v=C 

o=- 34 6232272 S20CC2id3 IK IF'l 131.220.32.^2 
c-Kelwrk Access Service (KASJ announcenenl 
i^InLernel Service Provider connecLiviLy inJo 
m=nas/ login 

c=TO RCF2324 +358-9-6524 827 
a=framing: ppp-asynch 
a=bearer: v. 90 

a=cellid:IP4 160.237.53.1/8 
m=nas/ login 

c=*TO RCF2324 +358-3-3157161 
a=f ranting: ppp-asynch 
a=bearer : v. 90 

a=cellid:IP4 160.238.45.1/4 
m=nas/ login 

c=*TO RCF2324 +358-2-4182732 
a=f r aming : ppp-asynch 
a=bearer : v . 90 

a=cellid:IF4 160.238.46.1/4 
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1. INTRODUCTION 



This is the collection of specifications for the announcement server to be build in the project 
ASAB (Advanced Service Announcement for Broadcasting). 

This specification is divided into three parts. In the first part we the functional (or 
architecture) specification of the server. This includes background and context for the 
system. In addition, we describe the system giving an overview and explaining the 
functionalities to be implemented in the announcer. 

The second part is the server technical (or component/implementation) specification of 
tryhe server. 

The last part serves as test specification. 

The common terms of reference used in the project ASAB are listed in the Annex A. 
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2. REFERENCES 
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PART 1 - SERVER FUNCTIONAL SPECIFICATION 
3. CONTEXT 
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Figure 3-1, The reference network topology 



The Figure 3-1 illustrates the reference network topology we consider in project ASAB. 
Additionally, the figure shows the logical placement of service annoucement server with 
respect to other entities in the network. 
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4. FUNCTIONAL ARCHITECTURE 

III 




Figure 4-1, Functional architecture of the service announcing system 



The functional architecture of the entire service a nnou cement system with is depicted in the 
Figure 4-1 . The main functional components are: 

Announcement server 

The announcement server is the main component of the system, tt takes care 
about composing the service announcement, sending them out as SDP over 
SAP and rescheduling them. The announcement server is associated with a 
set of databases, which define its configuration and behaviour. 

Cell broker 

There is one cell broker per one logical cell in the system. The cell broker is 
actually a system function, which can is implemented by the last hop 
announcement server associated with a particular cell. Depending on the 
configuuration, the announcement server can act as a plain annouce merit 
server, a cell broker, or both. 
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The cell broker is in charge of what is announced in the cell it has control 
over. The cell broker receives SDP announcements from two sources. First, it 
receives announcements from the other announcement servers in the 
backbone as ASAB internal multicast transmissions. Second, the 
annoucement server is associated with a set of databases that desribe which 
service annoucements to compose and send. 

Thus, the cell broker function is to decide which announcements should be 
transmitted to the actual cell. Also, the cell broker does translation between 
ASAB internal SAP multicast addresses to the multicast addressing used in 
UBA. Last, the cell broker ensures that the pace of announcement sending 
complies with the agreed bandwidth limits. This means that the cell broker 
acts as logical a filter-mapper-scheduler. 

Database servers 

The database servers contain four logical databases. First, the service 
description database contains the incredients for the basic SDP [1] service 
announcements. The second database, the announcement control 
information database contains the control information about how to announce 
services described in the first database. Third, the mapping databse contains 
the special cell-to-IP and connectivity mappings defined in ASAB protocol 
specification [3]. Last, the configuration database contains information of how 
the server is configured to work. 

It is envisioned that every announcement server (whether implementing cell 
broker functionality or not) has a local database server associated. However, 
this is not required. An annoucement server could use a local database for 
configuration and connectivity mappings, for example. The same server could 
then use a centralised, remote database for fetching the service descriptions. 



Management interfaces 

Each of the main components has a management interlace. The purpose of 
these interfaces is to allow system manager to monitor and adminstrate the 
server. Also, these interfaces provide other UBA system modules a way to 
inter-operate with the announcement server system. 
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PART 2 - SERVER TECHNICAL SPECIFICATION 
5. ANNOUNCEMENT SERVER 
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Figure 5-1, Announcement server components 

Components of the announcement server include 

• Abstract database accessors 

• For control info 

• For basic sdp descriptions 

• For ASAB specific mapping information (extended SDP) 

• For server configuration info 

• JDBC database driver 

• JDBC Type-IV, 1 00% Java 

• DB Change poller 

• Polls the changes that happen In control DB 
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Queues 



When a change occurs, the target queue is modified accordingly. The 
modification might be adding/removing an SDP or adding/removing a 
control element 



• There are multiple queues in an annoucement server. The meaning of a 
queue is to enable higher level of grouping the announcements that are 
prepared at the server. The idea is that a queue represents somehow 
grouped announcements. In addition, SAP announcement that originate 
the same queue will have the same IP multicast address as 
destination.This way, annoucement servers that implement cell brokers 
can subscribe to get certain types of announcements by just joining the 
respective multicast groups. 

• The scheduling policy of the queue depend on a single parameter, 
bandwidth limit (bwjimit). If the limit is set to 0, the queue follows blindly 
the configuration given an the controljnto DB. Otherwise the sender 
associated with the queue will requlate the pace of transmissions. 

Multicast receiver/filter, which contains 

• Multicast receiver and multicast-group-to-queue-mapper 

• This does essentially the same as DB change poller. This component 
installs new descriptions into correct queues as soon they are received. 



Interfaces to other UBA system components and management 
• Management interface 



5.1 JDBC Drivers 
[Jani] 



5.2 Database accessors 

[Jani] 



5.3 Queue 



IMCJKIA 

Nokia Research Center 
Toni Paila 



ASAB SERVER SIDE 



vO.046 



12(35) 
ASAB-D3 



Ordered by 

activation 

time 



Vectors of 
SDP 

containers 
keyed by 
Control entry 



Control 




Control 




Control 




Control 




Entry 




Entry 




Entry 




Entry 
















Figure 5-2, Queue internal buffers 



5.4 MulticastReceiverMapper 
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Figure 5-3, MulticastReceiverMapper operation 

The MulticastReceiverMapper structure is depicted in the Figure 5-3. There are three main 
components in a MulticastReceiverMapper. 

• Multicast Listener listens for multicast SAP annoucements via a socket. The multicast 
groups are defined in server configuration database asab_config. The groups that the 
MulticastListener listens is sum of all the to-be-listened addresses in the database. 

• QueueMapper maps the incoming multicast SAP packets to correct queues. It uses the 
ReceiverMapperTable to achieve that. 

• ReceiverMapperTable contains mappings from a multicast address to a set of queues. 
In fact, the ReceiverMapperTable is the memory of the MulticastReceiverMapper. 



Multicast address 
(ASAB internal SAP 
address) 


Address range 


Vector of references to target queues 


224.10.10.2 


1 


{Queuel , Queue2, Queue4} 


224.10.15.6 


1 


{Queuel , Queue3) 


224.100.4.0 


20 


{Queue2, Queue4) 



Table 5-1, Example of ReceiverMapperTable contents 
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The basic operation of MulticastReceiverMapper is annotated with numbered steps in the 
Figure 5-3. 

0. Configuration information is inserted to ReceiverMapperTable (an example is shown in 
Table 5-1). The information originates from the database asab_config. 

1 . MulticastListener is initialised/updated with a set of to-be-listened multicast addresses. 

2. MulticastListener sends a received multicast SAP announcement to QueueMapper for 
further mapping to queues. 

3. QueueMapper queries the ReceiverMapperTable to find out which queues to send a 
copy of announcement. 

4. ReceiverMapperTable returns a vector of references to target queues. 

5. QueueMapperTable inserts a copy of the received packet to each queue referenced by 
the result vector in 4. 

5.5 DbChangePoller 



5.6 Cell broker function 

The cell broker functionality is distributed in the announcement server to several places. 
Queue configuration database holds ASAB-SAP to UBA-SAP mapping information 

• What is the target multicast group of this queue 

• Which multicast groups from the backbone will map to this queue 
It also holds the tittering information 

• If a ASAB internal multicast group does not appear in the queue 
configuration, the queue won't receive or relay any packets from that 
group 

Sender-scheduler 

• Normal announcement server queues handle this task. 



5.7 File: Startup.properties 
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6. DATABASE SERVER 




Figure 6-1, E/R-model of the information in the databases 



NOKIA 

Nokia Research Center 
Toni Paila 



ASAB SERVER SIDE 



v0.046 



16(35) 
ASAB-D3 



The database server is simple. It only consists of a MySQL server and the databases. The 
E/R-model of the information in the databases is shown in the Figure 6-1. 



This information is consequently divided into tables. Furthermore, there are four separate 
databases which hold the tables. The descriptions per database are: 



Database 

IICUI1C 


Description 


Tables included 


asab_control 


Contains tables that define how the 

fhp annni inf^PinpnfQ arp fimnnprl anrl 

11 Iw Cll II IwUI Iv^l lid 119 Qlv UlvUpvU Cil III 

scheduled. 


controMnfo 
mutticastjisten 


asab_sdp 


Contains tables that define the 
content of service/session 
descriptions 


sdp 

time_description 

attribute_description 

media_description 


asabjmapping 


Contains tables that define special, 
ASAB-specific mappings, such as 
cell-to-IP -mapping and NAS 
announcements 


dvb_param 

cell_tojp 

access_map 

nas_group 

nas_map 


asab_config 


Contains tables for server 
configuration 


queue_config 



The management interface to the databases is provided directly with the MySQL client. 



6.1 Database tables for basic session descriptions 



6.1 .1 Service description directory (TABLE asab_sdp.sdp) 



Field name 


Key 


Type 


Notes 


sdpjd 


X 


integer 


unique key, not null 


v version 




char 


v, (protocol version) 


o user name 


x< 


varchar 


o, "-" | (user login) 


o session id 


x l 


bigint 


o, NTP 


o version 




bigint 


o, increase o session! d per modification 


o_network_type 


x' 


varchar 


o, "IN" 


o_address_type 


x' 


varchar 


o, "IN4" 


o_address 


X' 


varchar 


o, (address of the machine from which the session was 
created) | (FQDN) 


s session name 




varchar 


s, "MP3 stream" 


i information 




varchar 


i*, "Nice music..." 


u uri 




varchar 


u" 


e email 




varchar 


e* 7oo@ bar. corn" 


p_phone 




varchar 


p-, See RFC-2327 


c_network_type 




varchar 


c*. "IN" 

(connection information - not required if included in all 



2 As defined in RFC-2327 (Session Description Protocol) 
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media) 


c_address_type 




varchar 


c*. "IP4" 

(connection information - not required if included in ai! 
media) 


c_connection_address 




varchar 


c*. "224.2.17. 12/127* 

(connection information - not required if included in all 
media) 


b bandwidth 




varchar 


b*. See RFC-2327 


z_adjustment 




varchar 


z*. "2882844526 -1h 2898848070 (T 

note: ASAB groups all z subfields into one field 


k_method 




varchar 


k*. "dear" 


k_encryption_key 




varchar 


k*. See RFC-2327 



6.1 .2 Time description lookup table (TABLE asab_sdp.time_description) 



Field name 


Key 


Type 


Notes 


sdp_id 


X 


integer 


to which service description this belongs, not null 


t start time 




bigint 


t, 2873397496 


t_stop_time 




bigint 


t, 2873404696 


r_repeat_interval 




bigint 


r*. 604800 


r active duration 




bigint 


r* 3600 


r offsets 




varchar 


r* "0 90000" (zero or more repeat times) 



6.1 .3 Session attribute description lookup table (TABLE asab_sdp.session_attribute_description) 



Field name 


Key 


Type 


Notes 


sdp_id 


X 


integer 


to which service description this attribute belongs 


mediajd 


X 


integer 


to which media description in session 'sdpjd* this attribute 
belongs 

(0 means session-level attribute) 


a name 




varchar 


a* "connect" 


a value 




varchar 


a*, "1.23.4" 



6.1.4 Media description lookup table (TABLE asab_sdp.media_description) 



Field name 


Key 


Type 


Notes 


sdp_id 


X 


integer 


to which service description this belongs 


media id 


X 


integer 


part of key 


m media 




varchar 


m, 'Video" 


mjaort 




integer 


m, 49170 


m_number_of_ports 




integer 


m, 2 


m transport 




varchar 


m, "RTP/AVP" 


m tmt list 




varchar 


m, "31" 


i media title 




varchar 


i, "Foobar" 


c_network_type 






c*. "IN" 

(connection information for media) 


c_address_type 




varchar 


c*. "IP4" 

(connection information for media) 


c_connection_address 




varchar 


c*. "224.2.17.12/127' 
(connection information for media) 


b bandwidth 




varchar 


b* See RFC-2327 


k method 




varchar 


k*. "dear" 


k_encryption_key 




varchar 


k* f See RFC-2327 
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6.2 Database tables for Service announcement control information 



6.2.1 Service announcement directory (TABLE asab_control.control_info) 



rieiQ name 


i\ey 


Type 


iMoies 


serverjp 


X 


varchar{15) 


target server ip to which the control element refers 


server_port 


X 


integer 


target server port to which the control element refers 


Ctrl id 


X 


integer 


no duplicate control entries per server 


target_queue 




integer 


to which queue to put the SDP packets that belong to the 
scope this announcement control information 


sap_source_ip 




varchar 


IPv4 source adctess to appear in SAP header 
See SAP specification, chapter 3 


startjime 




bigint 


Starttime; when this control information activates, i.e. when 
to start announcing (in NTP) 


stop_time 




bigint 


Stop time; when this control information de-activates, i.e. 
when to stop announcing (in NTP} 


repeatjnterval 




bigint 


Announcing interval when the announcements are active, 
i.e. between start_time and stop_time 


repeatjncrement 




Bigint 


0 = When stopjime reached -> delete this control entry 
<other> = When stopjime reached do the following: 
starttime := stop time + repeat increment 



6.2.2 Grouped SDP table (TABLE asab_control.grouped_sdp) 



Field name 


Key 


Type 


Notes 


serverjp 


X 


integer 


target server ip to which the control element refers 


server _port 


X 


integer 


target server port to which the control element refers 


ctrl id 


X 


integer 


no duplicate control entries per server 


sdpjd 




integer 


Reference to asab_sdp.sdp (null only in multicast listen 
case) 


ref_in_dvb_param 




integer 


Reference to asab_mapping. dvb_param (null if not used) 


refJn_cell_to_ip 




integer 


Reference to asab_map ping, eel l_to_ip (null if not used) 


ref_in_ip_to_cell 




integer 


Reference to asab_mapping.ip to cell (null if not used) 


ref in multicast listen 




integer 


Reference to asab_control.multicast_listen (null if not used) 



6.2.3 ASAB internal SAP announcements from core network (TABLE asab_control.multicastJisten) 



Field name 


Key 


Type 


Notes 


ref in multicast listen 




integer 




asab_sap_address 




varchar 


the ASAB internal multicast c^oup to listen 
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6.3 Database tables for special mappings 

6.3.1 DVB parameters (TABLE asab_mapping.dvb_param) 



Needs asab_mapping.subcell 



Field name 


Key 


Type 


Notes 


ref_in_dvb_param 


X 


integer 




c address type 




varchar 


c», "IN4 n or "SI" 


celljd 


X 


varchar(8) 


Examples: 

"DVB/CELL SI 34567', or, 
"DVB/CELL IN4 12.13.14.15" 


bearer 




varchar(8) 


"a=bearer:dvb-t" 


framing 




varchar(8) 


" a^framing:dvb/mpe*' 


dvb_param_1 




varchar(8) 


"a=dvb-t-bandwidth: 8" 


dvb_param_2 




varchar(8) 


"a=dvb4-fft:8" 


dvb_param_3 




varchar(8) 


"a=dvb-t-oonstellation:16QAM" 


dvb_param_4 




varchar(8) 


"a=dvb-t-ooderate:2/3" 


dvb_param_5 




varchar(8) 


"a=dvb-t-guard-irtterval: 1/8" 


dvb_param_6 




varchar(8) 


"a=dvb-t-nierarchy: none" 


dvb_param_7 




varchar(8) 


,, a=dvb-t-hierarchical-priority : hf g h" 



6.3.2 DVB Subcell Information (TABLE asab_mapping.subcell) 
Needs asab_mapping.dvb_param 



Field name 


Key 


Type 


Notes 


celljd 


X 


varchar(8) 


Examples: 

"DVB/CELL SI 34567', or, 
'DVB/CELL I N4 12.13.1415" 


m media 




varchar{8) 


"m=nas/hone w 


subcell id 


X 


integer 


"a=subcell:1 450.2/60.3N/1244E/3.1/2.5" 


frequency 




varchar(8) 


"a=subcell: 1 450.2/60.3N/12.44E/3.1/2.5" 


coverage _pararn_1 




varchar(8) 


"a=subcell: 1 450.2/60.3N/12.44E/3.1/2.5" 


coverage_param_2 




varchar(8) 


"a=subcell:1 450.2/60.3N/12.44E/3.1/2.5" 


coverage_param_3 




varchar{8) 


"a=subcell: 1 450.2/60.3N/12.44E/3.1/2.5" 


coverage_param_4 




varchar(8) 


"a=subcell: 1 450.2/60. 3N/1 2. 44 E/3. 1/25" 
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6.3.3 Cell to IP mapping (TABLE asab_mapping.cell_to_ip) 



Needs asab_mapping.xmap 



Field name 


Key 


Type 


Notes 


ref_in_cell_to_ip 


X 


integer 




sesaon_group 


X 


integer 


reference to asab_mapping.xyz 



6.3.4 Session to cell mapping (TABLE asab_mapping.ip_to_cell) 
Needs asab_mapping.xmap 



Field name 


Key 


Type 


Notes 


ref_in_ip_to_cell 


X 


integer 




celLgroup 


X 


integer 


ref to asab_mapping.xyz 



6.3.5 xyz mapping (TABLE asab_mapping.xmap) 
Used by asab_mapping.cell_to_ip 
asab_mapping.ip_to_cell 



Field name 


Key 


Type 


Notes 


eel l_co n n ectio n_ad dr_type 




varchar 


"iP4 M | "sr 


cell connection address 




varchar 


"1.2.3.4" | u 32765 v 


o user name 




varchar 


o, "-" | (user login) 


o session id 




bigint 


o, NTP 


o_network_type 




varchar 


o, "IN" 


o__address_type 




varchar 


o, "IN4" 


o_address 




varchar 


o, (address of the machine from which the session was 
created) | (FQDN) 


session_group 




integer 




celljgroup 




integer 
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wm. 






* 










n 
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6.4 Database tables for server configuration 



6.4.1 Queue configuration for basic parameters (TABLE asab_config.queue_config) 



Field name 


Key 


Type 


Notes 


server Jp 


X 


varchar{15) 


target server ip to which the control element refers 


server_port 


X 


integer 


target server port to which the control element refers 


queuejd 


X 


integer 


identifier of the queue; not null 


target_sap_ip 




varchar 


Destination IP address in packet carrying SAP messages 
from this queue 


target_sap_port 




integer 


Target SAP port for the socket (this is for the future, if the 
queue needs to listen the annoucements itself) 


bwjimit 




integer 


the bw limit (refer to SAP specification) in bits per second. 
If this is 0, there is no limit 



7. MANAGEMENT INTERFACE 




Figure 7-1, Overview of service&management interface operation 



7.1 Management architecture 

The management architecture bases on the the following principles: 



• Through one management unit you can access and configure arbitrary many 
announcement servers and databases. 



• Every component of the ASAB system can be managed as an independent unit. 
This allows e.g. every database to be configured independently without a 
running server (with a few exceptions, of course). 
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• No components are positional. In other words the management units, 
announcement servers and databases can be located in different servers. 

• Every component is functional as stand-alone unit and thus independent of the 
management unit. 

• The management unit is runtime configurable in certain limits. 

• Every announcement server has only one asab_config, asab_control, asab_sdp 
and asab_mapping database. Still one database can be used by multiple 
announcement servers. 



4 

<UBWCcre 



Announcement Server 1 



Queue 1 



StrvuMpnt 



Queue 2 



4 
4 



Announcement Server 1 



Queue 1 



Queue 2 



CtrfBitry [ CM Entry 



MoRadUap 



Saver 1 configuration: 
asab_ccnfig: DBS 1 
asab_ccntroI: DBS 1 
asab_sdp: DBS 1 
asab_mapping: DBS 1 



Server 2 configuration: 
asab_config: DBS 2 
asab_corrtroL DBS 2 
asab_sdp: DBS 1 
asab_mappJng: DBS 1 



SQL 



SQL 



r 

AS accessc 


Y 
r J 


DBC type IV 
driver 

j 


Management unit (Server) 


SO/ 


P connoc 


trvity 


Management interface (Client) 



Database Server 1 



DB asab_config 



DB asab 



>_sdp I 



DBasab control 



DB asab 



Database Server 2 



DB asab_conftg 



^ — 



DBasab control 



»_mappind 



Figure 7-2, An example of a ASAB configuration 



The management unit provides a remote management interface that you can control the 
ASAB system with. The data transfer between management unit and management 
interface is enabled by a point-to-point connecetion using SOAP RPC protocol. 

Connections between management unit and databases are simple SQL connections 
through Java JDBC drivers. 



AS and management unit connection protocol is still open, but SOAP seems to be strongly 
suggested also here. 
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The server's independency of the management interface is enabled by assingning a boot 
sequence which first searches the configuration locally, second inquires it from 
management unit and is still no confdiguration is found, starts as null. 



7.2 Management API 



The complete class diagram of the ASAB management inteface. Note that there's only six 
classes with services while other classes are more like data containers. 

I — ^ 

asat>_rngimjdfag_i_i.ps 



7.2.1 <AsabManagementlnterface> 

The management interface for ASAB servers & databases. One instance of this class can be used to manage 
arbitrary many ASAB servers. Each announcement server needs four databases (asab_config, asab_control, 
asab_sdp, asab_mapping) to be able to sent announcements. Despite databases and announcement servers 
can be accessed if all four databases are not configured. Serveridentffier addServer(ServerConfiguration) 
Add a new server under the management . Use modifyServerConflguration to modify a server configuration. 
Here and in the following methods in this class the server means the complex of AS and the databases 
associated with it Its mandatory that the servers IP address & port is defined in ServerConfiguration, although 
the defined server doesnt need to ^t exist. Database definition in the configuration are optional. Naturally the 
accessibility of databases depends on this. 

void removeServer(Serverldentifier) 

Remove a server under the management Only the configuration information of the server & databases is 
removed - the action of the server and the databases is not affected. 

Vector getServerldentlflersO 

Get a vector of the Serverldentifiers that are added to this management interface. 

ServerConfiguration getServerConflguratfon(Serverldent!1!er) 

Get the configuration of the server 

void modlfyServerConf!guratIon(Server1dentlfier, ServerConfiguration) 

Modify the configuration of a server. 

Serveridentffier readServerConflguratlon(Strfng, Ent) 

Connect to an existing stand-alone announcement server and read its configurations. This method is similar to 
addServer, except the configurations are not given by the user of the interface but instead from a server. 
Arguments are IP adctess (String) and port (int). 

Server Accessor getServerAccessor(ServertdentJfler) 

Get the accessor for a server. 

ConflgDbAccessor getConflgDbAccessor(Serverfdentlfier) 

Get the accessor for a database asab_config of a specific server. 

ControlDbAccessor getContro(DbAccessor(Serverfdentffier) 

Get the accessor for a database asab_control of a specific server. 



SdpDbAccessor getSdpDbAccessor(Serverfdentffier) 

Get the accessor for a database asab_sdp of a specific server. 
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MappfngDbAccessor getMapplngsD bAccessor(Serverl den ti tier) 

Get the accessor for a database asab_mapping of a specific server. 

S erverCo nfig u ration 
-String serve r_lp 
-int serverjDort 

-DbConfiguration configDbConflg 
-DbConfiguration controlDbConUg 
-DbConfiguration sdpDbConfig 
-DbConfiguration mappingDbConfig 

DbConfiguration 
-String dbDriver 
-String dbMgmtSystem 
-String dbHostlp 
-int dbPcrt 
-String dbName 
-String usemame 
-String password 



This accessor accesses the announcement server. 

ServerState getServerStateO 

Get the current state of the server. 

void startQueue{Queueidentifler) 

Start a queue. 

void stopQueue(QueueJdentffler) 

Stop a queue. 

void disableMcRecelverMapperf) 

Stop listening the multicast addresses configured. 

void enableMcReceiverMapperO 

Start listening the multicast addresses configured. The sap packet received are sent forward to queues 
configured. 

ServerState 

-Queueldentifieit] runningQueues 
-Boolean isMcReceiverMapperRunning 



In addition to their own methods, aO four database accessorsConfigDbAccessor, Control DbAccessor, 
SdpDbAccessor, MappingDbAccessor implement similar database functions, which are listed here. 

void appendDb(DbAccessor) 

Appends another database to this database. Appending a database to an empty database is in practice 
duplicating. This operation doesnt affect the database which accessor is given as an argument. 

void emptyDbO 

Empty the database. 

Identifier add(Content) 

Add a Content to the database. When modifying an existing Content, use modifyContent instead. As return you 
get an Identifier referring to the Content 

void remove(ldentffler) 

Remove a Content from the database. 



7.2.2 <ServerAccessor> 



7.2.3 <DbAccessor> 
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Vector getldentifier$() 

Get a vector of identiers of the Contents in the database. 

Content getContent(ldefitifier) 

Get a Content element that the Identifier refers to. 

void modifyContefit(lden tiller, Content) 

Replace the Content (in database) that Identifier refers to with Content given as argument. 



Here's how the terms above differ in different accessors: 

DbAcoessor is 
in ConfigDbAcoessor ConftgDb Accessor 
in ControlDbAccessor: Control Db Accessor 
in SdpDbAccessor: ScfcDbAcoessor 
in MappingDbAccessor: MappingDbAcoessor 

Identifier is 

in CortfigDbAcoessor Queueldentifier 

in ControlDbAccessor: ControlEnlryldentifier 

in SdpDbAccessor: Sc^Packetldentifier 

in MappingDbAocessor: 1) DvbPararnldentifier, 2) CellTolpMappingtldentifler, 2) Cell Identifier 
Content is 

in ConfigDbAcoessor QueueConfiguraton 
in ControlDbAccessor: Control Entry 
in SdpDbAccessor: ScfePacket 

in MappingDbAocessor: 1) DvbPararn, 2) CellTolpMapping, 3) Cell 



This DbAccessor accesses the database asab_config. 

QueueConfiguration 
-String target_sap_ip 
-int target_sap_port 
-int bwjimit 



This DbAccessor accesses the database asab_corrtrol. 

void InsertCtriEntiyfntoQueuefCtrlEntryfdentlfier, Queueldentifier) 

Set a control entry to a queue. The queue and control entry must have been added to the databases of the 
same announcement server before an control entry can be addressed to a queue. 

void removeCtrlEntiyFromQueue(Ctr1Entryldentffier, Queueldentifier) 

Remove a control entry from a queue. 

Vector getCtrIEntries(Queueldentl1Ier) 

Get control entries inserted into a queue. Vector contains CfrlEntryidertftifier objects. 

Queueldentifier getTargetQueue(CtrfEntryfdentftfer) 

Get queue identifier by control entry. 



void InsertToControIEntryfObject, CtrfEntrytdentftJer) 

Attach an object to acorrtro! entry. The object given as can be either SdpPacketJdentifier, McRecMapConfig, 
CellTotpldentifler or DvbPararn MApping. 



7.2.4 <ConfigDbAccessor> 



7.2.5 <ControlDbAccessor> 
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void removeFromControlEntrytObject C til En tryl den tiller) 

Remove an object from a control entry. The object given as can be either SdpPacketldentjfier, 
McRecMapConfig, CellTolpldentifier or DvbParamMapping. 

Vector getSdpPacketldentf 1ler$(CtrfEntryfdentif!eT) 

Returns a vector of SdpPacketlderttifier objects. 

Vector getMcReceiverMapperCon1Igs(CtrlEntry1dentltler) 

Returns a vector of McRecMapConfig objects. 

Vector getOvbParamMapplngs (CtrtEntryldentJfler) 

Returns a vector of DvbParamMapping objects. 

Vector gelCeflTof pMapptng$(CtHEntryfdent!fler); 

Returns a vector of CeDTolpldentier objects. 

Vector getMcReceJverMapperCtrf Entries() 

Get a vector of CtriEntryidentifier objects that contain McReceiverMapperConfig objects. 
Vector getDvbParamMapplngCtrlEntrlesO 

Get a vector of CtriEntryidentifier objects that contain DvbParamMapping objects. 
Vector getCeUTotpMapplngCtrfEntriesO 

Get a vector of CtriEntryidentifier objects that contain CellTolpMappingldentifier objects. 
CtrlEntry 

-String sap_source_ip 
-long startjime 
-long stop_time 
-long repeatjnterval 
-long repeatjncrement 



This DbAccessor accesses the database asab_sdp. 

SdpPacket 
-int sdp_type 
-String vVersion 
-String oUsemame 
-long oSessionld 
-long ©Version 
-String oAddressType 
-String o Address 
-String sSessionName 
-String information 
-String uUri 
-StringeEmail 
-String pPhone 
-String cNetworkType 
-String cAddressType 
-String cConnectionAddress 
-String bBandwidth 

r Timings which belong into this sdp packet 7 
-Vector turnings 
-String zAdjustement 
-String kMethod 
-String kEncryptionKey 

r Session attributes which belong into this sdp packet 7 
-Vector aSesaonAttributes 

r Media descriptions which belong into this sdp packet 7 
-Vector mMedaDescriptions; 



7.2.6 <SdpDbAccessor> 
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MediaDescription 
-int media Id 
-String m Media 
-int mPort 

-int mNumberOfPorts 
-String mTransport 
-String mFrntList 
-String iMediaTitle 
-String cNetworkType 
-String cNetworkAddress 
-String cConnectionAddress 
-String bBandwidth 
-String kMethod 
-String kEncryptionKey 

TimeDescription 
-long tStartTime 
-long tStopTlme 
-long rRepeatlnterval 
-long rActiveDuration 
-String rOffsets 

SessionAttribute 
-MedaDescription medald 
-String aName 
-String aValue 



This DbAccessor accesses the database asab_mapping. 

Note: The method hierarchy in this accessor is still under development. 

DvbParam Mapping addDvbParamMapplngO 

Generate a new DvbParamMapping object The object is used to map DvbParams to CtriEntrys. 

void removeDvbPaiamMappfng(DvbParamMappfng) 

Remove a DvbParamMapping. 

Vector getDvbParamMapplngs() 

Gets a vector of DvbParamMapping objects. 

DvbParamMapping is ony an unique identifier given by the database. For the time being all mapping 
datastructures must be constructed manually. 

DvbParam 

-DvbParamMapping refjn_dvb_param 

-Ceilldentifier celMd 

-String bearer 

-String framing 

-String dvb_param_1 

-String dvb_param_2 

-String dvbj>aram_3 

-String dvb_param_4 

-String dvbj3aram_5 

-String dvbj3aram_6 

-String dvb_param_7 

SubCell 

-int subcelljd 

-String m_media 

-String frequency 

-String cove rage_param_ 1 

-String cove rage_param_2 



7.2.7 <MappingDbAccessor> 
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-String coverage__param_3 
-String cove rage_param_4 

CellTolp 

-Cellldentifier celMd 
-DvbParamldentifier sdp_celljd 
-String ip_ad dress 
-String ip_source 



-String c_addressjype 
-Stringcelljd; 

r A vector of SubCefl objects. At least one subCell is needed. 7 
-Vector subCells 



Cell 
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7.3 Example case 



Configuring announcement server from the beginning to send one session 
announcement with a DVB cell paramemeter announcement included 



giant 



AsabManaoementtnterface 



ConfioObAccessor 



MvSQL 



Add new 
server 



Add queue 



acWServer{ServerConfig\B^t]on£Serwridentfier 



getCcnfigDbAccesscr(Server1derrt}fier): CcnfigDtxAccesscr 



addOueu e(Queu eCcnfiguraticn): Queu el dentifier 



Management / DB 
connectivity 

(create connection to asab_config) 



jdbc : INSERT INTO asab_oonfig . 



getSdpDbAccessor(ServerlderTtifier): SdpDbAccessor 



Add Sdp 
packet 



StfpPtaAopgseoi 

, (create connection to asab_sdp) 



addSdpP acket<SdpPacket): SdpPacketl dentifier 



jdbc : INSERT INTO asab_sdp 



ge*MappngDbAccessor(Serverfdentifier): MappngDbAccessor 



Add mapping 



"(create connection to asab_mapping) 



adcDvbPararnMapp1ng(^DvbParamMapping 



addCefl():CeIII dentifier 



adoI>^arafn(r^PajBm)DvbPararnIdentifler 



jdbc : INSERT INTO asab_mapping . 



jdbc : INSERT INTO asab_mapping .. 



jdbc : INSERT INTO asab.mapping ... 



getControl DbAc cesser^ Server! dentifier): CcntroDbAccessor 

i 

£ 



Add new 
control entry & 
configure it 



(create connection to asab.ctri ) 



adoX»Errtry(ControIEntry):arfErtfy1d8ntmer 



: }dbo : INSERT INTO asab_ctr1 . 



insertCWEntrylntoQueue(C£rrtro{Ertryld Queueldentrfier) ! 



Jdbc : UPDATE asab_otr1 . 



InsertimoClrtEntrytSdpPacketJdenttfter, CtriEntryldentHler) 



jdbc : UPDATE asab_ctr1 . 



[f^mntoC^r1Errtry(DvbPararnMapplng. CtrlErrtrytderrtifler) 



jdbc : UPDATE asab_ctrt ... 



getServerAc oessor(Serv©ridentifier): ServerAccessor 



Start queue and 
inquire for the 
state of the server 



ServerAcoessor 



Acces?9f m ttlP AS 



startQueue(Queueidentifier) 



getServerStateO ServerState 



Management / AS 
connectivity 

(start queue) 



(state inquiry) 
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PART 3 - SERVER TEST SPECIFICATION 

This part lists all the test cases for ASAB server. The tests include both component tests as 
well as functional tests. 



8. COMPONENT TESTS 
8.1 Test drivers 



For component tests, there are test drivers for each tested module/component. The tests 
belong to package nrc.asab.tests. For example class nrc.asab.server.Queue has a test 
driver nrc.asab.tests.Queue_testdriver. 

The driver classes are runnable. One should use test number(s) as parameters. For 
example, the following command runs tests 5-10 for class Queue. 

~ ova nrc. asab. Leclc , Queue_ I eel driver 5 1C 

See the Javadoc-documentation for test cases and further information. 



8.2 Testing coverage 







1 




2 




i 





9. FUNCTIONALITY TESTS 
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ANNEX A - TERMS OF REFERENCE 



This chapter defines the terms used in ASAB project. In the following definitions,. 



Announcement 

control 

information 


Annoucement control information controls how the service descriptions 
should be announced. 


Annm inpomont 

Server 


^orwpr in tho riictrihi ittnn notu/nnV or in tho 1 IRA cnno notwnrlf «fhir , h 

OCIVCI III UlC UIOlllUUUUII IICIVVUII\ UI III U1C VJD/A VAJIC MClVVVlfl, WIIIVII 

creates service announcements and sends those to correct cells/links. 


Service 


The words service and session are used in a mixed way 

Service is something network offers and provides to end user. Services 
can be divided into individual services which are meant for one user or 
multiparty services which are aimed to two or more users. Examples of 
individual services are for example: video-on-demand and network 

arrocc /sirs /v^nno/*ti\/ttv# nr Hit ninac uuitH Hifforant r*Hora/'*toric4i/*c^ 
dlsvCdO \dl\d. sajI INCvllVliy, UI Ull piped Willi UlUCIciH l^l ldldClclidllOo^. 

Multiparty services can be divided to private and public services, 
tzxarnpico ur mumpony services are DruaucaSi news service, uroacicosx 
file distribution service, multicast of web pages, mp3 distribution by 
broadcast, etc. 


Service 

announcement 


Also called session announcement due to the close relevance to SAP. 
The sen/ice announcement is a message that contains service/session 
description. The service announcement is the vehicle to convey the 
description from announcer to potential service users. 


Service 
description 


Also called session description due to the close relevance to SDP. The 
service description defines the type of service and other parameters 
related to it. 
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ANNEX B - UML CLASS DIAGRAM OF THE SERVER 
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Title of invention: 

A method for performing handover for multicast session in 
uni-directional access system. 


INVENTION REPORT RECEIVED 






;Ratatf.Conuritee;^ 


THE DESCRIPTION OF THE INVENTION 




MUST BE ATTACHED 
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Inventor's name, employee number, title and 
nationality *) 

Toni Paila, 10000517, Research Engineer, 
Finnish 


Home Address: *) 

Everstinkuja 1 c 66 
02600 Espoo 
Finland 


Business Unit and cost 
centre: 

NRC 1007950 



Line Managers): Kari A. Rissanen 



Project : *) ASAB 



Project Manager: Toni Paila 



Office address: *) NRC Ruoholahti A427 



Phone: *) +358718037389 



Fax *) +358718036856 



The invention becomes public on: 



/ am/ We are the sole/ and original inventor(s) of this invention. 

The company may, by virtue of applicable legislation, be entitled to full or partial rights to the invention. 

1/ We acknowledge my/ our 'obligation to sign as inventor(s) all documents that may be required for protecting the 

invention in different countries. 

Applicable to inventions made by inventors employed in Fl, DK, DE and SB only. 

Date: 

Signature(s) of lnventor(s): 



*) See the instructions 



/ have read and understood the invention described in this Invention Report 
Date: 
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INSTRUCTIONS FOR COMPLETING THE INVENTION REPORT 

This Invention Report form is used in cases where an invention has been made by an 
employee of the Company. This Invention Report is confidential. Only the Patent 
Department may make copies of signed Invention Reports in order to request opinions or 
reply to the inventor(s). 

The inventor completes the Invention Report and the description of the invention. The 
inventor does not fill in the 'Invention Report received 1 field. This field is filled in by the 
Patent Department. The Invention Report must have the names of all the inventors and 
their home addresses. If there is not enough space for all the names, addresses etc, 
please write them on a separate attachment. The first mentioned inventor is assumed to 
be the contact person in matters concerning the Invention Report. In the fields of office 
address, phone and fax, please fill in the contact person's information. Fill in the project 
field, if the invention is made in a project. The original Invention Report is signed by all 
inventors. Each page of the original Invention Report is signed by a Manager. In case it 
is difficult to obtain Manager's signature your Patent Department will take care of it. 

It is suggested that the Invention Report and the description of the invention should be 
filled in as thoroughly as possible. If drawings or other kind of information cannot be 
attached to this form, they should be delivered separately. 

The signed Invention Report is given directly to the local or business unit's Patent 
Department. Invention Report should also be sent by E-mail to the Patent Department. 
The Patent Engineer will inform the inventor of receiving the Invention Report. The 
Patent Engineer will obtain any expert opinions needed to properly evaluate the 
invention, will procure the Company's decision and inform the inventor accordingly. 
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DESCRIPTION OF THE INVENTION 



1. Field and background of the invention 

The field of the invention is data networking in unidirectional access systems. More pre sice ty the invention 
relates to digital broadcast systems capable of broadcasting datagrams and receivers capable of receiving 
those, respectively. The invention will be explained in terms of TCP/IP networking suite, but a skilled 
person knowing the area can easily generalise the main ideas to suit any form of data networking. 

The background of invention lies in two NRC projects, DRiVE and ASAB. In DRiVE we design and specify 
a so called hybrid radio network, which by definition consist of multiple, possibly administratively 
independent, standalone radio access systems. In DRiVE the main question is how to offer the end users 
multimedia services over heterogenous radio access systems transparently. Also, the goal is to make the 
service provision cost-efficient, both for end user and the network operators. The multimedia services here 
may consist of both multicast and unicast services. This invention, however, is applicable for multicast 
services. 

In project ASAB we desing and implement session (also called service) announcement facility for a 
broadcast system. The work contains two main parts. First, there is a service announcement server. 
Second, we design extensions to Session Description Protocol to make it capable of expressing more 
than just basic IP connectivity in fixed networks. Such extended announcements describe, for example, 
physical parameters of a DVB-T cell (frequency, MAC, and other link-level parameters). In addition, the 
announcements descibe logical mappings that the user can use to find out how to reach the session he is 
interested. For example, given a multicast IP session, in which physical cells is it reachable. This mapping 
can also appear in reverse direction: given a physical cell, which multicast IP sessions are supported in 
that. This, the protocol specification work in ASAB is highly important for this invention. 

2. A summary of the invention 

The invention presents a way a (mobile) end user of a broadcast digital access system can perform cell- 
to-cell hand-over while preserving continuity of service. Here the service is assumed to be IP multicast 
session. It is easier to figure out the invention if one assumes that the multicast session is receive-only. 
However, the invention is equally applicable to multicast sessions that are not receive-only. 

In the invention, there is a (mobile) end user that tunes to a digital broadcast data bearer. First user gets 
logical mapping messages that announce a presence of a multicast session. The user joins the session 
and starts receiving it. While receiving, the continuosty received logical mapping messages keep him 
updated about contents of the neighbouring (horizontal or vertical) cells. When reception of the current 
bearer signal goes down, has errors, or fades out, the user uses the gathered logical mappings to select a 
new physical or logical cell to attach to. After this the user joins the session and starts receiving it. 

3. Describe the problem which the invention overcomes 

The problem is best explained with an example. When the user is moving he will pass a sequence of 
broadcast cell coverage areas. The user is receiving a session in one cell that he has tuned. When the 
user goes beyond the edge of the coverage area the reception will fade out if nothing is done. Surely, 
there are cases the user would like to preserve the session continuity. 
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4. How was the problem solved earlier? 

One way is to manually search for a new bearer. 

DVB-T standards might have some simple mechanism for performing some kind of DVB-T specific hand- 
over. (For an answer please consult DVB-T specialist) 

5. How does the invention improve earlier solutions? Advantages and disadvantages of 
the invention? 

Enables end user to make more intelligent selections based on (possibly extensive) learned knowledge 
base. 

6. Drawings and brief description of the drawings 



Cell A 



1. "Sessionid-1 on Cell-A" 

2. "Cell-A parameters" 



±± 



CellB 



3. (Optionally) Retune to the Cell-A 

r— ' ) A. Join multicast group 'm* that 
represents Sessionid-1 



User 



represents ' 
Figure 1 



Cell A 



5. Datagrams of group 'm' 

6. "Sessionid-1 on Cell-A and Cell-B' 

7. "Cell-B access parameters" 



User 



Cell B 



Figure 2 



c; 



Cell A C^> 

8. Unk of Cell-A is losi\^ 



CellB 



3'. Tune to Cell-B 



User 9 Look U P mappings for Sessionid-1 
' -> found Cell-B + its parameters 



Figure 3 
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Cell A 



Cell B 



5\ Datagrams of group W 

6\ "Sessionid-1 on Cell-A and Cell-B" 

7\ "Cell-A and Cdl-B 
access parameters" 



±± 



User 



4'. Join multicast group 'm' that 
represents Sessionid-1 



Figure 4 



There are four figures (Figures 1 to 4) that present the sequence of events and actions that take place 
according to this invention. The following explanation details the sequence. Below, the 'user 4 is assumed 
to be intelligent service browser or equivalent - not the actual end user of the terminal equipment. 



0. First, the user is attached to Cell-A and is receiving a logical announcemnt channel. This 
can be either predefined or dynamically configure IP multicast address. The broadcast 
network makes session announcements and mapping announcements available on this 
logical announcement channel. 

1 . User receives SDP announcement of session that has identifier Sessionid-1 . There is 
also a mapping that tells that Sessionid-1 is available in Cell-A as well as in Cell-B. 

2. User receives detailed link-level access parameters of Cell-A. 

3. User optionally retunes to Cell-A (in case of DVB-T, user might need to change the MAC 
address or PID in the receiver end) 

4. User joins the multicast group 'm' that was announced to represent Sessionid-1 . Note 
that because user does not have an uplink, the join message is merely registered the 
operating system and the IP stack. However, it does not send any concrete IGMP join 
message anywhere. 

5. User starts to receive datagrams of multicast group 'm* on Cell-A 

6. While receiving group 'm\ the user still receives session announcements and logical 
mappings. In this message, for example, Sessionid-1 is announced together with 
information that the Sessionid-1 is available on Cell-A as well as on Cell-B. 



7. User receives detailed link-level access parameters of Cell-B 

8. Reception of Cell-A signal may be lost for variuos reasons. The user may have left the 
coverage area, the Cell-A transmitter may experience a malfunction, there may be 
interference from some other source, etc. 

9. User looks up the received mappings for Sessionid-1 . He finds that Sessionid-1 is 
available on Cell-B. User also looks up for Cell-B and learns the detailed link-level 
access parameters. 



3\ User tunes to Cell-B. (Note, from this point the logic follows numbering starting from 3.) 
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4*. User joins the multicast group W that was announced to represent Sessionid-1 . 



5*. User starts (continnues) to receive datagrams of multicast group 'rrV on Cell-B 

6'. While receiving group 'm\ the user still receives session announcements and 
logical mappings. In this message, for example, Sessionid-1 is announced 
together with information that the Sessionid-1 is available on Cell-Aas well as 
on Cell-B. 



7. A more detailed description of the invention (if known at the moment) 

See 6 above. 

8. Explain, how the invention is/can be implemented. Which would be the best mode of 
implementation? 

If the announcement capability already exists the implementation will have impact to end users, only. 
There are two ways to implement. First, as operating system level function, or the as intelligent service 
browser (preferred). 

9. Explain how we can recognise if a competitor is using the same product/feature? 



10.1s it planned to use the invention in a Nokia product? If so, when and in which product? 
Is the invention standard related? 

NVO/NEW/IPDC and project ASAB are designing and implementing announcement server that is capable 
of performing the announcing system. That system might become a part of Nokia product by the end of 
year 2002. 

11. Abbreviations 

ASAB Advanced Service Announcement for Broadcasting 
DVB-T Digital Video Broadcast Terrestrial 
SDP Session Description Protocol 

1 2. Any further comments 
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I hope you are able to draft this new application. 
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Attached please find a first draft application (13 pages, inluding claims and abstract) and figures (5 additional pages, 
figures 1-7) for the above-referenced matter. Please have the inventors review the draft and provide any comments or 
changes. Specifically, please have them at least answer the questions embedded in the application in [ALL CAPS IN 
BRACKETS]. As this Application has a file-by date of November 19, 2001, PLEASE PROVIDE ANY COMMENTS 
TO US BY NOVEMBER 12, 2001 so that we will have time to prepare the revised draft and return it to you for 
approval. As always, please do not hesitate to contact us with any questions. We look forward to receiving your 
comments soon. 
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Ross Dannenberg 

Banner & Witcoff, Ltd 
1001 G Street, NW 
Washington, DC 20001-4597 
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are hereby notified that any dissemination, distribution, retention, archiving, or copying of the communication is strictly 
prohibited. If you have received this communication in error, please notify us immediately by return e-mail, telephone, 
or facsimile. 
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Attached please find a revised draft application and drawings for the above-referenced case, as well as formal 
declaration and assignment documents. Please have the inventors review the revised draft and, assuming all is in order, 
sign and return the executed declaration and assignment documents. 

In reviewing the revised draft and accompanying papers, please note: 

1) Also attached is a separate document showing the changes made in "redline" format, to more easily demonstrate the 
revisions from the previous draft 

2) Please confirm the inventors' citizenship information in the attached declaration document, as we only received 
citizenship information for the first named inventor. Please make any necessary corrections on the attached declaration 
document. 

3) Please confirm the inventors 1 address information. Specifically, Rod Walsh has a different address than that provided 
with a previous application on which he is a named inventor. Please make any necessary corrections on the attached 
declaration and assignment documents. 

Please let me know if you have any questions or if any other changes are required. As this application is due to be filed 
by November 19, please let us know as soon as possible if changes are required. Otherwise, we will file the application 
as soon as we receive the executed documents. Thank you for allowing us to be of assistance, and we look forward to 
hearing from you soon. 

Regards, 
Ross 

Ross Dannenberg 
Banner & Witcoff, Ltd 
1001 G Street, NW 
Washington, DC 20001-4597 
Direct: (202)508-9153 
Direct Fax: (202) 585-5908 
Main: (202) 508-9100 
Main Fax: (202) 508-9299 
rdannenberg@bannerwitcoff.com 

IMPORTANT/CONFIDENTIAL: This message contains information from the law firm of Banner & Witcoff; LTD. 
which may be privileged, confidential, or exempt from disclosure under applicable law. If the reader of this message is 
not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you 
are hereby notified that any dissemination, distribution, retention, archiving, or copying of the communication is strictly 
prohibited. If you have received this communication in error, please notify us immediately by return e-mail, telephone, 
or facsimile. 
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